home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1258.txt < prev    next >
Text File  |  1994-08-01  |  10KB  |  283 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          B. Kantor
  8. Request for Comments: 1258                      Univ. of Calif San Diego
  9.                                                           September 1991
  10.  
  11.  
  12.                                BSD Rlogin
  13.  
  14. Status of this Memo
  15.  
  16.    This memo documents an existing protocol and common implementation
  17.    that is extensively used on the Internet.  This memo provides
  18.    information for the Internet community.  It does not specify an
  19.    Internet standard.  Distribution of this memo is unlimited.
  20.  
  21. Protocol Description
  22.  
  23.    The rlogin facility provides a remote-echoed, locally flow-controlled
  24.    virtual terminal with proper flushing of output.  It is widely used
  25.    between Unix hosts because it provides transport of more of the Unix
  26.    terminal environment semantics than does the Telnet protocol, and
  27.    because on many Unix hosts it can be configured not to require user
  28.    entry of passwords when connections originate from trusted hosts.
  29.  
  30.    The rlogin protocol requires the use of the TCP.  The contact port is
  31.    513.  An eight-bit transparent stream is assumed.
  32.  
  33. Connection Establishment
  34.  
  35.    Upon connection establishment, the client sends four null-terminated
  36.    strings to the server.  The first is an empty string (i.e., it
  37.    consists solely of a single zero byte), followed by three non-null
  38.    strings: the client username, the server username, and the terminal
  39.    type and speed.  More explicitly:
  40.  
  41.         <null>
  42.         client-user-name<null>
  43.         server-user-name<null>
  44.         terminal-type/speed<null>
  45.  
  46.         For example:
  47.  
  48.         <null>
  49.         bostic<null>
  50.         kbostic<null>
  51.         vt100/9600<null>
  52.  
  53.    The server returns a zero byte to indicate that it has received these
  54.    strings and is now in data transfer mode.  Window size negotiation
  55.  
  56.  
  57.  
  58. Kantor                                                          [Page 1]
  59.  
  60. RFC 1258                       BSD Rlogin                 September 1991
  61.  
  62.  
  63.    may follow this initial exchange (see below).
  64.  
  65. From Client to Server (and Flow Control)
  66.  
  67.    Initially, the client begins operation in "cooked" (as opposed to
  68.    to "raw") mode.  In this mode, the START and STOP (usually ASCII
  69.    DC1,DC3) characters are intercepted and interpreted by the client to
  70.    start and stop output from the remote server to the local terminal,
  71.    whereas all other characters are transmitted to the remote host as
  72.    they are received.  (But see below for the handling of the
  73.    local-escape character.)
  74.  
  75.    In "raw" mode, the START and STOP characters are not processed
  76.    locally, but are sent as any other character to the remote server.
  77.    The server thus determines the semantics of the START and STOP
  78.    characters when in "raw" mode; they may be used for flow control or
  79.    have quite different meanings independent of their ordinary usage on
  80.    the client.
  81.  
  82. Screen/Window Size
  83.  
  84.    The remote server indicates to the client that it can accept window
  85.    size change information by requesting a window size message (as
  86.    described below) just after connection establishment and user
  87.    identification exchange.  The client should reply to this request
  88.    with the current window size.
  89.  
  90.    If the remote server has indicated that it can accept client window
  91.    size changes and the size of the client's window or screen dimensions
  92.    changes, a 12-byte special sequence is sent to the remote server to
  93.    indicate the current dimensions of the client's window, should the
  94.    user process running on the server care to make use of that
  95.    information.
  96.  
  97.    The window change control sequence is 12 bytes in length, consisting
  98.    of a magic cookie (two consecutive bytes of hex FF), followed by two
  99.    bytes containing lower-case ASCII "s", then 8 bytes containing the
  100.    16-bit values for the number of character rows, the number of
  101.    characters per row, the number of pixels in the X direction, and the
  102.    number of pixels in the Y direction, in network byte order.  Thus:
  103.  
  104.         FF FF s s rr cc xp yp
  105.  
  106.    Other flags than "ss" may be used in future for other in-band control
  107.    messages.  None are currently defined.
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Kantor                                                          [Page 2]
  115.  
  116. RFC 1258                       BSD Rlogin                 September 1991
  117.  
  118.  
  119. From Server to Client
  120.  
  121.    Data from the remote server is sent to the client as a stream of
  122.    characters.  Normal data is simply sent to the client's display, but
  123.    may be processed before actual display (tabs expanded, etc.).
  124.  
  125.    The server can imbed single-byte control messages in the data stream
  126.    by inserting the control byte in the stream of data and pointing the
  127.    TCP "urgent-data" pointer at the control byte.  When a TCP urgent-
  128.    data pointer is received by the client, data in the TCP stream up to
  129.    the urgent byte is buffered for possible display after the control
  130.    byte is handled, and the control byte pointed to is received and
  131.    interpreted as follows:
  132.  
  133.    02   A control byte of hex 02 causes the client to discard all buffered
  134.         data received from the server that has not yet been written to the
  135.         client user's screen.
  136.  
  137.    10   A control byte of hex 10 commands the client to switch to "raw"
  138.         mode, where the START and STOP characters are no longer handled by
  139.         the client, but are instead treated as plain data.
  140.  
  141.    20   A control byte of hex 20 commands the client to resume interception
  142.         and local processing of START and STOP flow control characters.
  143.  
  144.    All other values of the urgent-data control byte are ignored.  In all
  145.    cases, the byte pointed to by the urgent data pointer is NOT written
  146.    to the client user's display.
  147.  
  148. Connection Closure
  149.  
  150.    When the TCP connection closes in either direction, the client or
  151.    server process which notices the close should perform an orderly
  152.    shut-down, restoring terminal modes and notifying the user or
  153.    processes of the close before it closes the connection in the other
  154.    direction.
  155.  
  156. Implementation Notes
  157.  
  158.    The client defines a client-escape character (customarily the tilde,
  159.    "~"), which is handled specially only if it is the first character to
  160.    be typed at the beginning of a line.  (The beginning of a line is
  161.    defined to be the first character typed by the client user after a
  162.    new-line [CR or LF] character, after a line-cancel character, after
  163.    resumption of a suspended client session, or after initiation of the
  164.    connection.)
  165.  
  166.    The client-escape character is not transmitted to the server until
  167.  
  168.  
  169.  
  170. Kantor                                                          [Page 3]
  171.  
  172. RFC 1258                       BSD Rlogin                 September 1991
  173.  
  174.  
  175.    the character after it has been examined, and if that character is
  176.    one of the defined client escape sequences, neither the client-escape
  177.    nor the character following it are sent.  Otherwise, both the
  178.    client-escape character and the character following it are sent to
  179.    the server as ordinary user input.
  180.  
  181.    If the character following the client-escape character is the dot
  182.    ".", or the client-defined end-of-file character (usually control-D),
  183.    the connection is closed.  This is normally treated by the server as
  184.    a disconnection, rather than an orderly logout.
  185.  
  186.    Other characters (client-defined, usually control-Z and control-Y)
  187.    are used to temporarily suspend the rlogin client when the host has
  188.    that ability.  One character suspends both remote input and output;
  189.    the other suspends remote input but allows remote output to continue
  190.    to be directed to the local client's terminal.
  191.  
  192.    Most client implementations have invocation switches that can defeat
  193.    normal output processing on the client system, and which can force
  194.    the client to remain in raw mode despite switching notification from
  195.    the server.
  196.  
  197. A Cautionary Tale
  198.  
  199.    The rlogin protocol (as commonly implemented) allows a user to set up
  200.    a class of trusted users and/or hosts which will be allowed to log on
  201.    as himself without the entry of a password.  While extremely
  202.    convenient, this represents a weakening of security that has been
  203.    successfully exploited in previous attacks on the internet.  If one
  204.    wishes to use the password-bypass facilities of the rlogin service,
  205.    it is essential to realize the compromises that may be possible
  206.    thereby.
  207.  
  208.    Bypassing password authentication from trusted hosts opens ALL the
  209.    systems so configured when just one is compromised.  Just as using
  210.    the same password for all systems to which you have access lets a
  211.    villain in everywhere you have access, allowing passwordless login
  212.    among all your systems gives a marauder a wide playing field once he
  213.    has entered any of your systems.  One compromise that many feel
  214.    achieves a workable balance between convenience and security is to
  215.    allow password bypass from only ONE workstation to the other systems
  216.    you use, and NOT allow it between those systems.  With this measure,
  217.    you may have reduced exposure to a workable minimum.
  218.  
  219.    The trusted host specification is ordinarily one of a host name.  It
  220.    is possible, by compromise of your organization's domain name server,
  221.    or compromise of your network itself, for a villain to make an
  222.    untrusted host masquerade as a trusted system.  There is little that
  223.  
  224.  
  225.  
  226. Kantor                                                          [Page 4]
  227.  
  228. RFC 1258                       BSD Rlogin                 September 1991
  229.  
  230.  
  231.    a user can do about this form of attack.  Luckily, so far such
  232.    attacks have been rare, and often cause enough disruption of a
  233.    network that attempts are quickly noticed.
  234.  
  235.    When the file containing a user's list of trusted logins is
  236.    inadvertently left writeable by other users, untrustworthy additions
  237.    may be made to it.
  238.  
  239.    Secure authentication extensions to the rlogin protocol (Kerberos,
  240.    et al) can greatly reduce the possibility of compromise whilst still
  241.    allowing the convenience of bypassing password entry.  As these become
  242.    more widely deployed in the internet community, the hazards of rlogin
  243.    will decrease.
  244.  
  245. Security Considerations
  246.  
  247.    See the "A Cautionary Tale" section above.
  248.  
  249. Author's Address
  250.  
  251.    Brian Kantor
  252.    University of California at San Diego
  253.    Network Operations C-024
  254.    La Jolla, CA 92093-0214
  255.  
  256.    Phone: (619) 534-6865
  257.  
  258.    EMail: brian@UCSD.EDU
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Kantor                                                          [Page 5]
  283.